Part of the Frontier website. © copyright 1996 UserLand Software.

cactus Picture Your Second Script

Creating a new table and writing a script in it.

First question -- where do I put my scripts?

Then, the second question -- how do I write a new script?

The answers follow...

Where?

There are lots of places to put new scripts. The object database is a lot like the Macintosh file system, but much faster and more flexible, and definitely a lot more scripting friendly. But there's a tradeoff for the new power -- you have to learn how to use it.

Some examples of special places...

Scripts that live in the system.agents table run in the background. Using the clock.sleepFor verb you can determine how often the script runs. This is useful for monitoring ongoing realtime processes, and is real important when Frontier is used on a server machine. Frontier is a multi-threaded environment? All the scripts run concurrently -- you can run as many as you like.

The system.verbs.traps table holds scripts that run in response to incoming Apple Events. It's the basis for the connection between Frontier and WebStar, and also plays a crucial role in the connection between Frontier and Netscape.

The system.deskscripts table holds scripts that will eventually live on the Finder's desktop.

So, the place to put your new script may depend on the function that script intended to perform. And while there are many conventions, you definitely do not have to understand all those conventions to be a productive Frontier script writer.

Tables are like folders

By the way, in case it hasn't become obvious, a table in Frontier is like a folder in the Finder, with two important exceptions:

1. A table can contain scalars, small things, like numbers and strings. You'd never want to use a whole file just to store a person's name or email address. It would be very wasteful, and be way too slow; but in Frontier it's economical, it works, it's not wasteful.

2. Scripts can access the contents of a table very quickly and simply. The object database is really just the symbol table for all currently running Frontier scripts. But it's a structured symbol table, and it's disk-based and it retains its values (it's "persistent") even when you quit and relaunch Frontier.

Let's do a simple script

First, create a new table at the root level, called "tests":

Bring the main window to the front, flip down the flag, and click on the Object DB button.

Choose "New Sub-Table" from the Table menu. Type in tests, then click on OK. The root window should look like this:

rootafternewtable Picture

Double-click on the triangular wedge to the left of the word "tests" to open the table.

Choose "New Script" from the Table menu. Type in script1, then click on OK. A new script window opens. It should look like this:

newemptyscript Picture

Enter the script

Press cmd-X twice to get rid of the first two lines that were automatically created. OK, I admit that we made a mistake when we did the first release of Frontier, and it can be hard to correct early mistakes. Those first two lines are confusing. That's why we just cut them.

Type in the following text and then press Return:

   local (i)

Next, type in the following text and press Return:

   for i = 1 to 50

Then, type in this text, but do not press Return:

   msg (states.nthState (i))

Finally, press the Tab key to indent the final line under the "for" line.

Here's what your window should look like now:

initialscript Picture

Running the script

Click on the Run button in the script window to run the script. You should see the names of all fifty United States quickly roll thru the main window in Frontier.

Click on the Debug button to step thru the script in the debugger. When you do this, the button bar at the top of the window changes to show the debugging options. You can click on the Step button to single-step thru the script; In will dive into a subroutine call; Out surfaces out of a subroutine call; Follow runs the script with the cursor reflecting the location of the interpreter as the script is executing; Go resumes normal script running; Kill halts the script; and Lookup displays the value of the variable whose name you have selected.

If you're new to programming the debugging options may seem confusing. They are new ideas you may have never seen before. But, if you want to get complex scripts working reliably, a debugger is not an option, it's a necessity.

Understanding a script

For now, I'm assuming that you already know the basic programming concepts of looping, if statements, and so forth. From that point, how do you figure out what a particular verb does, things like states.nthState and msg?

There are two methods available to you in Frontier. Usually one or the other will get you the information you need.

Method #1: cmd-double-click on the name. Try it out. Hold down the cmd-key and double-click on msg in the last line of the script. A window opens showing you something that's mysterious: 

on msg (s) 
   kernel (lang.msg)

Not much information here! That's because msg is a built-in verb, it's implemented in the Frontier kernel. But it's OK, because all the built-in verbs are written up in the DocServer database. You should now try...

Method #2: control-double-click on the name. DocServer launches and opens to the page describing the verb.

Moral of the story -- when you want to find out what a verb does, first cmd-double-click on its name; if you don't get what you want, control-double-click on it.

Ice the cake

OK, now we have a script that runs, is debugged and does something interesting. The next step is to make it easy to run the script.

Bring the main window to the front, and click on Menu Bar. When the menu window opens, choose "Full Collapse" from the Menubar menu. The window should look like this:

initialmenubarwindow Picture

Press Return to open a new line. Type in your first name. Press Return. Type My First Script, press the Tab key to indent it, then press Enter.

Here's what my window looks like:

initialmenubar2 Picture

Now, click on the Script button in the menu window. A script window opens. Type:

   tests.script1 ()

Press Enter. Now look up at Frontier's menu bar. Your name is there! Pull down the menu, choose My First Script. Watch the main window. All 50 states quickly roll thru.

The menu editor plays a big role in Frontier, and also in conjunction with apps that support the Menu Sharing protocol. For now, you know how to edit Frontier's menu bar. You can add your own commands, or reorganize it any way you like. I strongly encourage you to use this feature to the max. [On the other hand, it's probably not a great idea to reorganize the UserLand, Net and Suites menus. They contain commands that eventually you probably will find useful, but everything else is up for grabs.]

Where to go from here...

Want to get some more ideas what scripts can do? Open up the suites.samples table. You'll see lots of sample scripts. You can step thru them in the debugger, watch them run, and get ideas for your own scripts.

Put your new scripts in the test table we just created. I'll explain more about agent scripts and startup scripts, etc in future writing. Run your scripts from the button bar in its window; or for scripts you want to run a lot, link them into Frontier's menu bar.

And you can learn a lot by poking around inside the object database. You'll find that much of Frontier is implemented in scripts.

cactus Picture This page was last built with Frontier on a Macintosh on Sun, Oct 13, 1996 at 7:06:04 AM. Thanks for checking it out! Dave